I don't think we should add a mock for this. Returning true in all cases makes a pretty broad assumption about what a pipeline is expecting. For example, consider the following example code:

if (fileExists(outputDir)) {
  sh 'make clean'
}
sh 'make'
sh 'make install'

... and now imagine a corresponding unit test:

@Test
void testStuff() {
  // run pipeline
  assertEquals(2, helper.callStack.findAll { call ->
    call.methodName == 'sh'
  }.size())
}

This is a fairly basic example, but my point is, I don't think we can assume that this mock should always return true (or also always return false, for that matter). I realize one can override this by registering a new mock, but the current behavior of leaving this step unmocked means that it is the user's responsibility to decide how this method should behave.

If we were to add a mock for fileExists to this library, I'd prefer it to be similar to the readFile mock, meaning that there would be a separate helper method to register the output that should be returned for a given filename. If you're ok with that solution, I'd be happy to implement it and we can make a corresponding issue to track it.

See #312.

#312 Looks good to me, thanks! Closing PR.